The present invention relates to a method for analyzing transmitted protocol data units (PDUs) of a general protocol for communication between Object Request Brokers (ORB).
Methods for analyzing transmitted protocol data units of a general protocol for communication between Object Request Brokers (ORB) for the purpose of representing the contained messages as completely as possible are generally known.
CORBA is described in “Wissen” [Knowledge], pages 108–113 in the article “CORBA, tibemehmen Sie”, Services: Basisdienste für den ORB, [“CORBA, Take Over”, Services: Basic Services for the ORB], by Uwe Seimet. It was also described in a publication entitled “Validating Interaction Patterns of CORBA Based Network Management Systems” by Guido Carl Gerd Aschemann and Ying Lu within the frame work of “NOMS 2000, 2000 IEEE/IFIP, Network and Management Symposium” “The Networked Planet: Management Beyond 2000”, Apr. 10 through 14, 2000, Hilton Hawaiian Village, Honolulu, Hi., and is used to distribute applications over several operating system processes. CORBA allows non-proprietary, interhost communication of distributed applications. In this context, a distinction is made between the roles of client and server. An application in the client role transmits a request to another application which works in the server role. This request is processed by the application in the server role, and a corresponding response is returned to the client. The general protocol for communication between two Object Request Brokers is used as the protocol for conveying these messages. In TCP/IP-based networks, one uses its special form, the so-called “Internet Inter-ORB Protocol (IIOP)”. The information as to which contents can be exchanged between client and server is established using an object-oriented interface description language (IDL).
In the event of an unexpected behavior of a distributed application or during its acceptance test, it may be necessary to monitor the communication between client and server to be able to draw conclusions on the behavior of the individual application components. For example, the literature reference cited above describes the following procedures:    the distributed application can be extended on the client side or on the server side in such a manner that the exchanged GIOP messages are also completely or partially routed to a component of the distributed application that is intended for recording and evaluation;    the PDUs exchanged between client and server can be recorded by a trace tool and decoded using additional knowledge on the type of the exchanged messages and on the products used. The decoding of the messages can be carried out manually or in an automated manner.    an application, which has been developed exclusively for test purposes, is integrated into the communication between client and server. As a server, this application receives a request from the client and, as a client, routes this request to the server. The response is returned accordingly. As a result of this, all PDUs can be monitored and evaluated by this test application.
These known methods have the disadvantage that the passive recording of the General Inter ORB Protocol (GIOP) PDUs exchanged between client and server alone is not sufficient to completely decode the message. This results from several causes, which will be shown below.    As a rule, only the values, for example, 123, but not their type code, for example, whole number, are encoded in a GIOP PDU. Therefore, it is not possible to determine just from a PDU the number of parameters contained in a PDU or the type of the values.    The name of the invoked method is not encoded in an invocation in its full context. There is missing a unique identification of the interface definition in which this method is declared. If identical methods should have been defined in different interface definitions with different signatures, then it is not possible to identify the method that is actually encoded, given identical value encoding length.    While the agent on the server side, via the auto-generated and published “target address”, is able to associate incoming requests with a particular CORBA object, a trace tool according to CORBA standard is indeed able to check the content of the target address for equality according to the index but unable to make an association with a concrete object and with the interface definition underlying the object. Only with the aid of proprietary extensions of the CORBA standard is it possible to obtain information from the content of a target address using a trace tool.    In CORBA, provision is made for an object reference to be transferred from the server to the client, circumventing the GIOP protocol, for example, as a text file on a diskette. When this object reference, which is exchanged as an interoperable object reference (IOR) which serves to uniquely address CORBA objects on the basis of the IIOP protocol, also contains information on the associated interface definition, this item of information is generally never exchanged between client and server again. Consequently, there is no way for a CORBA trace tool to obtain this information without actively querying the application components involved in the communication. This, however, would be contrary to the paradigm that a trace tool is only allowed to monitor passively.
Consequently, the problem exists that it is indeed possible for a single GIOP PDU to be uniquely correlated and decoded in the context known to client and server but that there is no unique and standard-compliant possibility for a recorded PDU to be decoded outside of this known context.